Distributed computer systems have become more widespread as computer networks have developed. Distributed computer systems comprise multiple computer systems connected by one or more networks such that the resources of the computer systems can be shared. Processes instructed by a local computer system can be executed on a remote computer system. The connecting networks can include Local Area Networks (LANs), Wide Area Networks (WANs) and global networks such as the Internet.
One form of distributed architecture in which multiple computer processes may cooperatively perform tasks is under a “client-server” relationship. In such a relationship, a “client” or calling computer process issues or sends a request for a remote procedure to a “server” or receiving computer process which executes the procedure. It will be appreciated that whilst one computer process may function as a client which issues a procedure request and another may function as a server when it executes the procedure, any computer process may function as both a client and a server in different capacities. The terms “client” and “server” may also be applied to peer systems.
Requests are passed between application programs running on the client and server computer systems by communication described by an interface.
As new functionality is implemented in computer processes and environments, remote procedure interfaces often may be enhanced to support the new functionality. As is common practice with computer programs or applications, enhancements to an interface are embodied in a new version of the interface.
To support a new version of an interface, both the client and the server utilising the interface must support the new version. However, in many distributed computer systems it is impossible or impractical to upgrade all clients and servers at the same time to a new version of a remote procedure interface. This is particularly true in shared or public networks. Consequently, multiple versions of an interface may exist in a distributed computer system.
In existing systems, multiple interface versions are handled by allowing servers to support multiple versions, with clients usually supporting only single versions of an interface. Clients can access both old and new versions of an interface simultaneously for as long as the clients may need to access the old versions. This allows clients to test their use of a new interface while doing useful work with the old interface.
A problem that arises is that servers must maintain old interfaces and implementations and, probably multiple old levels, for long periods which will eventually make maintenance and functional progress costly or even impossible.
The problem stems from the fact that the server has no information which can reveal whether any client depends on the old interface because a client may not require the service for some unpredictable time. In an organisation where clients and servers are under a single management scope, it is possible to audit the software and enforce upgrades to new versions. However, in the context of public networks such as the Internet, such control is not possible and other means of communication and influence are needed.
The development of the Internet has resulted in the use of open or shared computing in which applications are freely and dynamically available to users via the Internet with no licence agreement to formalise any long-term relationship. Such systems result in further loss of control and influence over the version of interfaces used. Recent trends in the Internet are towards the use of ‘Web Services’ whereby standard functions, associated with a particular industry or infrastructure requirement, are established by a consortium of companies and thus represent a standard interface.
There are several approaches that are used in existing systems. Firstly, it is possible to provide an interface description which allows some flexibility in information content. One example is called the REST architecture described by R. T. Fielding which has few stable operations (such as a GET) on documents of arbitrary complexity. Another example is to provide extensible parameters available in some description languages such as XML. These approaches unavoidably provide imprecise information about the interface, including the ability to change content beyond the scope anticipated by the user. Therefore, they do not enable the description of and planning for changes.
A second approach is to accept that interfaces must be stable but, if new versions are found to be necessary, to broadcast information to all users and implementers of the interface. This method can be used where an application is part of a widely used infrastructure, such as the Domain Name Server (DNS) used in the Internet. RFC 921, published by the Internet Engineering Task Force (IETF) on their website, is an example of such a broadcast. Clearly the exploitation of such broadcasts must be limited to a small number of special cases if users are not to be swamped with information.
A third approach might be to provide a licensed program which exploits an interface available in a distributed system. The program can be distributed with a licence of limited lifetime, so providing information about the potential use of the facilities in the distributed system. This approach is not consistent with the requirement, characteristic of many technical standards in the Internet, to provide open interfaces which any client may freely implement.
A fourth approach is to continue to support old versions indefinitely as new versions are introduced. This approach constrains evolution of a service.